Visa Digital Report Requirements

Version 1.0 | Jan 2025

Important Note on Confidentiality, Disclaimers and Copyright

© 2025 Visa. All Rights Reserved.

Confidentiality: This document, and the information set out in this document, is proprietary and CONFIDENTIAL to Visa. It is distributed to you by Visa as a participant in the Visa payments system for your use only to the extent necessary to enable Visa programs. You acknowledge that the information contained herein (the 'Information') is confidential and subject to confidentiality restrictions contained in Visa's operating regulations or other confidentiality agreements that limit your use of the Information. In no event may this document or its information be duplicated, published, distributed, or disclosed, in whole or in part, to any third party, individual, or any other person, without prior written permission from Visa, and without expressly limiting by way of contract that person's use of this document and the information it contains to assisting you in managing your Visa programs. This document and the information set out in this document may not be used in connection with, or to support, any non-Visa programs or any non-Visa payment network, system, or scheme, including any non-Visa program that is co-badged or co-resident with a Visa program, in each case, without Visa's prior written consent.

Trademarks: The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively the "Trademarks") are Trademarks owned by Visa. All other trademarks not attributed to Visa are the property of their respective owners.

THIS PUBLICATION IS PROVIDED ON AN "AS IS", "WHERE IS", BASIS, "WITH ALL FAULTS" KNOWN AND UNKNOWN. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VISA EXPLICITLY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE LICENSED WORK AND TITLES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.

THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE MAINTAINED IN CONFIDENCE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE SPECIFICATION LICENSE OR OTHER WRITTEN AGREEMENT BETWEEN YOU AND VISA INC., VISA INTERNATIONAL SERVICE ASSOCIATION, AND/OR VISA EUROPE LIMITED.

Table of Contents

• Introduction
  • General Information
    • Scope
    • Audience
    • Reference Materials
• 1 Overall Architecture
  • 1.1 L2 Functional Test Tool
  • 1.2 Lab Proprietary Report Generator Tool
  • 1.3 Approval Services Report Review Process
• 2 XML Format Definition
  • Using the Table
  • Data Type Definition
  • 2.1 Report Summary Format
  • 2.2 Transaction Log Format
    • 2.2.1 Logging a <Contact> or <Contactless> Transaction
      • 2.2.1.1 Attribute "Exclude"
      • 2.2.1.2 Sub-Element <ReaderSpecifics>
    • 2.2.2 Example of a Log {TestID}.xml
  • 2.3 Digital ICS Format
    • 2.3.1. "Field" Element
    • 2.3.2 Example of the Digital ICS XML File
• 3 Base64 Encoded SHA-256 Hash
  • 3.1 Base64 Encoded SHA-256 Hash
  • 3.2 Example of the Digest Computation
• 4 Schema (.xsd) Files
  • 4.1 W3C XML Schema Definition Language, Version 1.1

Version History

This document provides information on how to process Visa’s machine-generated Test Plans. Tool Vendor shall implement the requirements into their Tool development.

Date	Version Number	Description
Jan 2025	1.0	First publication Highlighted changes from Draft Version 20240805: Updated naming convention for generated report package (See Req 1.5 for details). Corrected requirement numbering order. Removed important notes from Req 1.5 due to a contradiction with Req 1.3 Ensure test tool does not generate report when there is Fail test verdict with empty comment as described in Req 1.4. Clarification on Req 3.1. Introduce schema file for reader and non-reader test plan. Made editorial changes in several sections. Transform document to HTML format.

Introduction

This document provides detailed guidelines for standardizing and automating the Visa Level 2 Type Approval test reporting processes. It includes necessary steps to maintain consistency, accuracy, and efficiency in Visa Digital Report.

The guide is aimed at assisting stakeholders in comprehending the procedural and technical aspects of generating Visa Digital Report, which can streamline operations, minimize manual errors, and optimize resource use. All individuals involved must acquaint themselves with this standard to ensure seamless implementation and operation.

General Information

Scope

This document is applicable solely to Test Execution following the Visa Digital ART Test Plans.

Audience

This document is intended to guide Test Tool Vendors in generating XML reports and logs, assist Visa accredited laboratory in creating proprietary PDF reports using the Visa report template and serve as a reference for Visa Internal teams involved in validating the submitted materials.

Reference Materials

The following documents are referenced in this specification.

Reference	Document
[TestPlan]	Visa ART Test Plan. Please use the correct Test Plan corresponding to the execution.
[TechReq]	Visa Test Tool Technical Requirements for [TestPlan]. Please refer to the correct document corresponding to the Test Plan. Note: for VRTPKS Test Plan, the document will be “Visa Test Tool Technical Requirements for Reader Test Plans”
[CompanionGuide]	[TestPlan] Companion Guide for Test Automation. Please refer to the correct Companion Guide corresponding to the Test Plan.
[ReportTemplate]	Template document defined by Visa used as guideline by lab to generate PDF report

1 Overall Architecture

Before this initiative, Type Approval Report was delivered in the laboratory's proprietary template with test execution logs that varied among test tool vendors. This diversity made standardizing and automating the reporting process challenging.

The specifications in this document establish a standard reporting process, while still allowing for each lab to integrate their proprietary requirement within Visa Report Template guideline into the Type Approval Report.

First, the lab enters preliminary data into the test tool and executes the test. Once completed, the test tool generates XML ICS, XML Report, and XML Logs.

Next, using the Visa report template as the baseline, the XML Report is fed into the Lab Proprietary Report Generator Tool to generate a PDF Report. This step is crucial to keep consistent test case verdict while giving the laboratory the flexibility to create the PDF report compliant with the laboratory ISO requirement.

All produced files are then provided to Visa Approval Services for report scrutiny. Previously created XML files are then digitally utilized by Visa to automate the analysis of report review processes.

Should there be a requirement to revise the report, Visa will revert it back to the laboratory for necessary adjustments. Once the modifications have been made, the updated report is then resubmitted to Visa for subsequent rounds of report review procedures.

1.1 L2 Functional Test Tool

Req 1.1 L2 Functional Test Tool Must Comply to Test Plan and Guideline

L2 Functional Test Tool serves as a crucial element in standardizing and automating the reporting process. It is designed to execute and validate tests accurately according to the guidelines [CompanionGuide] set forth in the Visa Test Plan [TestPlan].

Req 1.2 L2 Functional Test Tool able to generate XML ICS, XML Report, and XML Logs

Once the test execution concludes, the test tool is responsible for generating all necessary files, intended for submission to Visa Approval Services. These files include the XML Report detailed in 2.1 Report Summary Format, the XML Logs described in 2.2 Transaction Log Format, and XML ICS as outlined in 2.3 Digital ICS Format. For in-depth implementation specifics, please consult the respective chapters.

Req 1.3 Ability to Update Report

Test tool must have the functionality to revise the generated report, catering to the common demand for report alterations in numerous submissions.

If there is a need to modify the report, such as altering any of its elements, or to revisit the transaction log by rerunning or adding new test cases, it is imperative that all related XML files accurately mirror these changes.

Req 1.4 Ability to add test verdict comment

Test tool must be equipped with the capability to enable users to insert a comment for each test verdict. This functionality is essential for the lab to provide detailed explanations or context regarding the test verdict. It will facilitate a deeper understanding of the test results and any subsequent actions that may be required.

The "Comment" attribute of the "Test" element within the Report Summary captures this comment. If the test verdict is "FAIL," an explanation is required in the comment attribute, and the test tool must not generate the report if there is a "FAIL" test with an empty comment. In this scenario, test tool must warn user that there is missing comment for failure test. However, additional information can also be provided for "PASS" or "NA" verdicts.

Req 1.5 Test tool generated report package

Test tool must generate XML files (ICS, Report summary and all test logs) in the following layout:

The generated report package shall be in a standard compressed format (.zip) and follow naming convention: "Report_{VTF#}_{TestPlanName}_{Timestamp}.zip", where:

• {VTF#} is the product’s assigned VTF number, such as “CDVISA01234A” or “LBVISA01234A”
• {TestPlanName} is the full name of the released test plan package, such as “VCPS_Reader_Test_Plan_v2_2d_Build_240405”
• {Timestamp} represent the time when the report is generated in UTC time format: YYYYMMDDHHMM. For example, “202501151525”.
  • YYYY: 4-digit of the year
  • MM: 2-digit month of the year
  • DD: 2-digit day of the year
  • HH: 2-digit hour using a 24-hour clock
  • MM: 2-digit minute

An example of report package name based on the above convention is “Report_CDVISA01234A_VCPS_Reader_Test_Plan_v2_2d_Build_240405_202501151525.zip”

The zipped package shall consist of the following components:

1. Report Summary: This file follows the naming convention "ReportSummary_{VTF#}_{TestPlanName}_{Timestamp}.xml". Detailed information about this format can be found in section 2.1 Report Summary Format.
2. Logs folder: This folder contains all the executed test case files in the format "{TestID}.xml". Detailed information about this format can be found in section 2.2 Transaction Log Format.
3. ICS file: This file follows the naming convention "ICS_{VTF#}_{TestPlanName}_{Timestamp}.xml". Detailed information about this format can be found in section 2.3 Digital ICS Format.

1.2 Lab Proprietary Report Generator Tool

Req 1.6 Lab Proprietary Report Generator Tool

It is important for a lab to have the capability to incorporate its proprietary information into the report. Each lab may have unique methods of presenting information tailored to their specific business needs.

This Lab Proprietary Report Generator Tool must maintain the structure of the Visa Report Template (i.e., PDF report looks and feel) [ReportTemplate], while simultaneously ensuring that all necessary information is included from the XML Report generated by the Test Tool from the previous process.

Req 1.7 Visa Report Template Mapping

Visa Report Template document [ReportTemplate] defines how PDF report looks and feel generated by lab proprietary test tool. This document maps all information from XML Report to its corresponding section. For other sections that are not mapped with XML Report, lab need to fill in the information.

1.3 Approval Services Report Review Process

With XML format and a standard report template, Visa can integrate automation software to improve and speed up the report review process. This reduces errors, quickens response times to labs, and allows for easy integration with different systems. It also enhances the flexibility to handle various types and volumes of reports.

Req 1.8 Final report package submission

The laboratory is required to provide the report that includes both the Test Tool generated report (as detailed in requirement 1.5) and the PDF generated report (as outlined in requirements 1.6 and 1.7).

In the event of any issues identified within the provided report, Visa reserves the right to return the report to the laboratory for necessary amendments. The capability of the Test Tool to update the report(as specified in requirement 1.3), should be utilized for these corrections.

2 XML Format Definition

Req 2.1 XML Structure Requirement

To allow uniform parsing, each XML file shall begin with a XML prolog, indicating an encoding of “UTF-8” or “utf-8”. Example: <?xml version="1.0" encoding="UTF-8"?>

The two file formats that shall be included for Report Submission, are defined below and each format is detailed in their respective tables:

• ReportSummary_{VTF#}_{TestPlanName}_{Timestamp}.xml is a summary of report to record the overall test execution results.
• {TestID}.xml is a test execution log to record the full APDU exchanges of a test and where applicable, related test outcomes. These logs is located under folder “Logs”.
• ICS_{VTF#}_{TestPlanName}_{Timestamp}.xml contains key parameters of the product’s features that are used in the test filtering logic for test execution of VISA ART Test Plans.

All elements, attributes and defined values used in the Tables are case-sensitive unless otherwise stated. The order of the occurrence of the elements or attributes is unimportant unless otherwise stated. Whitespace between tags is ignored as is leading and trailing whitespace for a tag’s value. Values that are of Hexadecimal String shall be in upper case and without whitespaces.

Using the Table

Each Table is used to describe the XML structure of the file formats and the Table comprises of four main columns:

Element/Node (1|2|3|4)	Occurrence (Min..Max)	Description	Content ([Condition]: DataType | Parameter | Value) / Example (e.g.)

1. Element/Node: Describes the XML elements residing in respective nodes of the XML hierarchical structure. "1" indicates the Root node of the XML and the subsequent numbers represent the child nodes in hierarchical order.

2. Occurrence: Describes the occurrence of the XML element within its indicated node and is used to facilitate schema check. ”Min” indicates the minimum occurrence required and ”Max” indicates the maximum occurrence allowed. For example:

   • 1..1 : Element is mandatory and can only occur once.
   • 0..1 : Element is optional and if present, can only occur once.
   • 1..var : Element is mandatory and can occur more than once.
   • 0..var : Element is optional and can occur more than once.

   The occurrence rule is bound to its parent element. If the parent element is not present or is empty, the occurrence rule for the child elements will not apply. The equivalent of this is available in the corresponding schema.xsd file (Refer to Schema (.xsd) Files).

3. Description: Describes the XML element and additional conditions if any.

4. Content/Example: Describes the Content of the XML element (Attributes and/or Text Content) and provides Example of how the XML element would be crafted. The Content is represented in format: “[Condition]: DataType | Parameter | Value”, where

   • ”Condition” defines if the Text Content or Attribute is [M] = Mandatory, [C] = Conditional or [O] = Optional.
     • For Text Content, only [M] is used to mandate that the Text Content must not be empty. [C] indicates that the presence of Text Content is dependent on other indicators (described specifically for each element), and [O] indicates that Text Content is optional. It is acceptable that Text Content defined as [C] and [O] indicates an empty element tag.
     • For Attributes, only [M] is used to mandate that the attribute must be present. [C] indicates that the presence of attribute is dependent on other indicators (described specifically for each attribute), and [O] indicates that Attribute is optional.
   • ”DataType” defines the data type of the Attribute/Text Content. ”Parameter” and ”Value” are used for Attributes.
   • ”Parameter” defines the name of the Attribute.
   • ”Value” (if used) defines the absolute value of the Attribute.

Attributes Example:

• [M]: String | Tag | "ART": Element has an Attribute "Tag" with a "String" Data Type and the Attribute Value is defined to be "ART".
• [O]: String | ID: Element may have an Attribute "ID" with a "String" Data Type. The Attribute Value is not defined.

Text Content Example:

• [M]: String: Element must not have an empty Text Content and the Text Content is of Data Type "String".
• String: Element records a Text Content of Data Type "String".

Data Type Definition

Table 1: Data Type Definition Table

Type	Base Type	Constraints	Description
String	String	--	Stores alphanumeric combination and text. Allows ASCII punctuations and symbols like '['. Includes values "yes" and "no".
Boolean	String	true, false	Enumeration field with values "true" or "false" only.
Hexadecimal	String	[A-F][0-9]	Hexadecimal representation with no whitespaces and in all uppercase.
Decimal	Numeric	--	Represents decimal numbers with arbitrary lengths. Examples: "5.0", "1.16", "1".
Integer	Numeric	--	Represent whole numbers with no fractional parts. Examples: "0", "1", "2".
UTCDateTime	Numeric	yyyy-mm-dd’T’hh:mm:ss’Z’	Format of Date-Time must be in standard UTC timestamp, ISO 8601 format. Example: 2020-06-15T14:32:00Z

This table describes the definition of the Data Type used in the XML structure or mentioned in the document.

2.1 Report Summary Format

Req 2.2 Report Summary XML Structure

The generated Report Summary XML file follows the naming convention: "ReportSummary_{VTF#}_{TestPlanName}_{Timestamp}.xml", where:

• {VTF#} is the product’s assigned VTF number, such as “CDVISA01234A” or “LBVISA01234A”
• {TestPlanName} is the full name of the released test plan package, such as “VCPS_Reader_Test_Plan_v2_2d_Build_240405”
• {Timestamp} represent the time when the report is generated in UTC time format: YYYYMMDDHHMM. For example, “202501151525”.
  • YYYY: 4-digit of the year
  • MM: 2-digit month of the year
  • DD: 2-digit day of the year
  • HH: 2-digit hour using a 24-hour clock
  • MM: 2-digit minute

An example of report package name based on the above convention is “ReportSummary_CDVISA01234A_VCPS_Reader_Test_Plan_v2_2d_Build_240405_202501151525.xml”

Req 2.3 Report Summary XML Structure

This file (in .xml format) summarizes the test execution session for a product under test and primarily contains the full list of the assessed test cases. Table 2: XML Format of the Report Summary describes the elements defined within the file structure.

File name: ReportSummary_{VTF#}_{TestPlanName}_{Timestamp}.xml

Table 2: XML Format of the Report Summary

Element/Node (1|2|3|4)	Occurrence (Min..Max)	Description	Content ([Condition]: DataType | Parameter | Value) / Example (e.g.)
TestReport	1..1	The Root element of the Report Summary. Contains attributes: "Tag" – an identifier to distinguish the format structure that is usable only on Visa’s ART Test Plans. "SchemaFile" – references the corresponding schema (.xsd) file for this XML format.	Attributes: [M]: String | Tag | "ART" Attribute Value is defined to be “ART” [M]: String | SchemaFile File begins with “ReportSummary_”, ends with file extension “.xsd” e.g.: <TestReport Tag=”ART” SchemaFile=”ReportSummary_Schema_v#.xsd”>…</TestReport>
_ LogDetails	1..1	Contains sub-elements that record the logging and test information.	e.g., <LogDetails>…</LogDetails>
_ _ Date-Time	1..1	Records the date & time of the report generation in the text content.	Text Content: [M]: UTCDateTime. e.g.: “2025-09-18T14:32:00Z”
_ _ LoggingTool	1..1	Contains sub-elements that record the information of the logging tool.	e.g., <LoggingTool>…</LoggingTool>
_ _ _ ProductName	1..1	Records the Name of the Test Tool in the text content.	Text Content: [M]: String. e.g., <ProductName>ART Test Tool</ProductName>
_ _ _ ProductVersion	1..1	Records the Version of the Test Tool in the text content.	Text Content: [M]: String. e.g., <ProductVersion>1.16</ProductVersion>
_ _ VTF	1..1	Records the VTF number of the product-under-test. The element shall not be empty and the VTF information can be obtained from the <VTF> element in the Digital ICS file.	Text Content: [M]: String. e.g., <VTF>LBWXYZ01234A</VTF>
_ _ TestPlan	1..1	Records in the text content, the Test Plan used in the report. The Test Plan can be obtained from the <TestPlan> element in the Digital ICS file.	Text Content: [M]: String. e.g., <TestPlan>VRTPKS_Test_Plan_v1_0a_Build_200615</TestPlan>
_ _ ExecutionType	1..1	Records in the text content, the type of execution run. The element must record either of the following: “FULL”, ”REGRESSION”, or ”TRANSACTION”. The value can be obtained from the <ExecutionType> element in the Digital ICS file.	Text Content: [M]: String. Value is case-sensitive and must be “FULL”, “REGRESSION” or “TRANSACTION” e.g., <ExecutionType>FULL</ExecutionType>
_ TestGroup	1..1	Contains sub-element that records the evaluation of individual test case execution. The test cases within the <TestGroup> shall be populated based on the execution order. Refer to Req 2.4 Test Population Requirement	e.g., <TestGroup>…</TestGroup>
_ _ Test	1..var	Contains information of a test in the attributes: “ID” – denotes the filename (excluding file extension) of the test case. “Verdict” – denotes the test outcome. “Comment” – records any comment that is required to explain any discrepancy from the expected result. Comment is mandatory for FAIL test verdict. Refer to Req 1.4	Attributes: [M]: String | ID [M]: String | Verdict | “PASS”/”FAIL”/”NA” Attribute Value is case-sensitive and takes only “PASS”, ”FAIL” or “NA” [M]: String | Comment e.g., <Test ID=”T_002_T2P_4_1_C01_01” Verdict=”PASS” Comment=” Test failed is expected as per ASQ12345”/>

<!--BZFOjb+DQHx1tf23EwBe/dA6LbXmsZvTeC1DSO6xwbo=-->

The last line of the file shall include an XML comment containing the digest of the Base64 encoded SHA-256 algorithm of the file, like the example above. For details on deriving the hash, refer to 3 Base64 Encoded SHA-256 Hash

Req 2.4 Test Population Requirement

The evaluation results for each test case are logged within the <TestGroup> element. The population of the test cases must be based on the execution order of the test session.

For [TestPlan] that has tests that could result in interruption (i.e., requiring human intervention in visual test cases) to the execution flow, it is important to follow the requirement described in the [TechReq] to effectively group-run test cases.

2.1.1 Example of ReportSummary.xml

Below is an extract of the file to illustrate the content structure:

This xml document should start with <?xml version="1.0" encoding="utf-8"?>

<TestReport xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Tag="ART" SchemaFile="ReportSummary_Schema_v2.xsd">
  <LogDetails>
    <Date-Time>2024-06-06T18:29:28Z</Date-Time>
    <LoggingTool>
      <ProductName>ICCSimTMat VRTPKS</ProductName>
      <ProductVersion>4.203.2-sha</ProductVersion>
    </LoggingTool>
    <VTF>CDVISA01234A</VTF>
    <TestPlan>VRTPKS_Test_Plan_v1_2a_Build_230512</TestPlan>
    <ExecutionType>FULL</ExecutionType>
  </LogDetails>
  <TestGroup>
    <Test ID="T_001_T2P_2_1_C01_01" Verdict="PASS" Comment=""/>
    <Test ID="T_002_T2P_2_1_C02_01" Verdict="PASS" Comment=""/>
    <Test ID="T_003_T2P_2_1_C03_01" Verdict="PASS" Comment=""/>
    <Test ID="T_004_T2P_2_1_C04_01" Verdict="FAIL" Comment="Failure is acceptable as per ASQ12345"/>
    <Test ID="T_005_T2P_2_1_C05_01" Verdict="NA" Comment="Online Pin is not supported"/>
    <Test ID="T_006_T2P_2_1_C06_01" Verdict="NA" Comment="Online Pin is not supported"/>
  </TestGroup>
</TestReport>
<!--S4rLyUh96mktanEWw4Zv6B5rXC8CFg1yRUP7aSuGlXA=-->

2.2 Transaction Log Format

Req 2.5 Transaction Log XML Structure

This file (in .xml format) details the logging of an executed test case. The communication exchanges between the Reader and Card/Mobile in a test are recorded in the log. Table 3: XML Format of the Log {TestID}.xml describes the elements defined within the file structure.

File name: {TestID}.xml, where {TestID} denotes the filename (excluding file extension) of the test case log i.e.: T_627_T2P_7_5_C01_01.xml

Table 3: XML Format of the Log {TestID}.xml

Element/Node (1|2|3|4)	Occurrence (Min..Max)	Description	Content ([Condition]: DataType | Parameter | Value) / Example (e.g.)
CardTerminalLog	1..1	The Root element of a Transaction Log. Applies for any form-factor transaction logging, i.e., Reader, Cards, Mobile. Contains attributes: "Tag" – an identifier to distinguish the format structure that is usable only on Visa’s ART Test Plans. "SchemaFile" – references the corresponding schema (.xsd) file for this XML format. Refer to Schema (.xsd) Files	Attributes: [M]: String | Tag | "ART" Attribute Value is defined to be “ART” [M]: String | SchemaFile File begins with “Log_”, ends with file extension “.xsd” e.g: for terminal test plan <CardTerminalLog Tag=”ART” SchemaFile=”Log_Reader_Schema_v#.xsd”>…</CardTerminalLog> e.g: for non-reader test plan <CardTerminalLog Tag=”ART” SchemaFile=”Log_Card_Schema_v#.xsd”>…</CardTerminalLog>
_ TestVerdict	1..1	Records the outcome of the test execution in the text content and must be either “PASS”, “FAIL” or “NA”	Text Content: [M]: String Value is case-sensitive and must only be “PASS”, “FAIL” or “NA” e.g., <TestVerdict>PASS</TestVerdict>
_ LogDetails	1..1	Contains sub-elements that record the administrative information related to the logging and the test.	e.g., <LogDetails>…</LogDetails>
_ _ Date-Time	1..1	Records the date & time of the report generation in the text content.	Text Content: [M]: UTCDateTime e.g., 2020-06-15T14:32:00Z
_ _ LoggingTool	1..1	Contains sub-elements that record the information of the logging tool.	e.g., <LoggingTool>…</LoggingTool>
_ _ _ ProductName	1..1	Records the Name of the Test Tool in the text content.	Text Content: [M]: String e.g., <ProductName>ART Test Tool</ProductName>
_ _ _ ProductVersion	1..1	Records the Version of the Test Tool in the text content.	Text Content: [M]: String e.g., <ProductVersion>1.16</ProductVersion>
_ _ VTF	1..1	Records the VTF number of the product-under-test. The element shall not be empty and the VTF information can be obtained from the <VTF> element in the Digital ICS file.	Text Content: [M]: String e.g., <VTF>LBWXYZ01234A</VTF>
_ _ TestPlan	1..1	Records in the text content, the Test Plan used in the report. The Test Plan can be obtained from the <TestPlan> element in the Digital ICS file.	Text Content: [M]: String e.g., <TestPlan>VRTPKS_Test_Plan_v1_0a_Build_2006125</TestPlan>
_ _ Reference	1..1	Records the filename (excluding file extension) of the test case in the text content.	Text Content: [M]: String e.g., <Reference>T_627_T2P_7_5_C01</Reference>
_ Transactions	1..1	Records all executed APDU commands-responses in their respective interfaces. Logging must be done in the exact same order as how the Transaction(s) are being executed.	e.g., <Transactions>… </Transactions>
_ _ Contact *	0..var	Optional element if a Contact Transaction is logged. Contains sub-elements that detail the actual APDU exchanges in a Contact Transaction.	Attributes: [C]: Boolean | Exclude ** | true This attribute is used only when the Transaction is used to facilitate proprietary run and is not expected from the actual test case. e.g., <Contact Exclude=”true”>…</Contact> e.g., <Contact>…</Contact>
_ _ _ Commands	0..1	Element is mandatory when the parent element is present and not empty. Contains sub-elements that encapsulate the APDU exchanges of the Transaction.	e.g., <Commands>…</Commands>
_ _ _ _ CommandResponse	1..var	Contains a set of <Command> - <Response> pairs to capture the APDU exchanges. These command-response pair elements must be logged in the order that they occurred.	Attributes: [C]: Boolean | Exclude ** | true This attribute is used only when the Command and Response within a transaction is used to facilitate proprietary run and is not expected from the actual test case. e.g., <CommandResponse Exclude=”true”>…</CommandResponse>
_ _ _ _ _ Command	1..1	Records a command APDU.	Text Content: [M]: String A command APDU must be hexadecimal strings, in upper case and without whitespaces e.g., <Command>0020208008241234FFFFFFFFFF</Command>
_ _ _ _ _ Response	1..1	Records a response APDU. May contain literal CARD_EXCEPTION if there was an error in the communication or be empty for some commands.	Text Content: [M]: String A response APDU must be hexadecimal strings, in upper case and without whitespaces e.g., <Response>9F5501009000</Response>
_ _ Contactless *	0..var	Optional element if a Contactless Transaction is logged. Contains sub-elements that detail the actual APDU exchanges in a Contactless Transaction.	Attributes: [C]: Boolean | Exclude ** | true This attribute is used only when the transaction is used to facilitate proprietary run and is not expected from the actual test case. e.g., <Contactless Exclude=”true”>…</Contactless> e.g., <Contactless>…</Contactless>
_ _ _ Commands	0..1	Element is mandatory when the parent element is present and not empty. Contains sub-elements that encapsulate the APDU exchanges of the Transaction.	e.g., <Commands>…</Commands>
_ _ _ _ CommandResponse	1..var	Contains a set of <Command> - <Response> pairs to capture the APDU exchanges. These command-response pair elements must be logged in the order that they occurred.	Attributes: [C]: Boolean | Exclude ** | true This attribute is used only when the Command and Response within a transaction is used to facilitate proprietary run and is not expected from the actual test case. e.g., <CommandResponse Exclude=”true”>…</CommandResponse>
_ _ _ _ _ Command	1..1	Records a command APDU.	Text Content: [M]: String A command APDU must be hexadecimal strings, in upper case and without whitespaces e.g., <Command>0020208008241234FFFFFFFFFF</Command>
_ _ _ _ _ Response	1..1	Records a response APDU. May contain literal CARD_EXCEPTION if there was an error in the communication or be empty for some commands.	Text Content: [M]: String A response APDU must be hexadecimal strings, in upper case and without whitespaces e.g., <Response>9F5501009000</Response>
_ ReaderSpecifics ***	0..1	Conditional element: Mandatory for Reader Test Plans to log all outcomes of the transaction. Element shall not be present for non-Reader Test Plans.	e.g., <ReaderSpecifics>…</ReaderSpecifics>
_ _ Transaction_Details ***	1..1	Records the XML content of the ETXN request as defined in the [Companion Guide] Refer to the [Companion Guide] for details on this element and its sub-elements. May contain literal COMM_EXCEPTION if there is an error in the communication between Test Tool and Reader Controller.	e.g., <Transaction_Details> <Test_ID>T_627_T2P_7_5_C01_01</Test_ID> <Transaction_Outcome>20</Transaction_Outcome> <AcquirerData>…</AcquirerData><IRWINData>…</IRWINData></Transaction_Details>
_ _ Visual Check ***	1..1	Records each visual event checks and its outcome according to the [TestPlan]. If there are no visual checks required of the test case, then this element shall be empty. Refer to [TestPlan] visual_list.xml for the list of test cases requiring Visual Check.	e.g., <VisualCheck/>
_ _ _ Events	0..1	Element shall be present if <VisualCheck> is not empty. Lists all visual event checks in the sub-elements.	e.g., <Events>…</Events>
_ _ _ _ Event	1..var	Records a visual event check and its outcome. Contains attribute: “ID” – records the name of the event check in the attribute value. The value of the value is defined in the [TestPlan].	Attributes: [C]: String | ID | e.g., <Event ID=”EVT_AID_PRINTED”>…</Event>
_ _ _ _ _ CheckPass	1..1	Records the outcome of the check, to indicate if the check has passed	Text Content: [M]: Boolean The outcome of the visual check shall be translated to a Boolean value of “true” if the check passed or a “false” if the check failed. e.g., <CheckPass>true</CheckPass>
_ _ _ _ _ Remarks	0..1	Contains tester’s comments (if any) on the visual checking event.	Text Content: [O]: String e.g., <Remarks/>

<!--BZFOjb+DQHx1tf23EwBe/dA6LbXmsZvTeC1DSO6xwbo=-->

The last line of the file shall include an XML comment containing the digest of the Base64 encoded SHA-256 algorithm of the file, like the example above. For details on deriving the hash, refer to 3 Base64 Encoded SHA-256 Hash

* refer to 2.2.1 Logging a <Contact> or <Contactless> Transaction

** refer to 2.2.1.1 Attribute "Exclude"

*** refer to 2.2.1.2 Sub-Element <ReaderSpecifics>

2.2.1 Logging a <Contact> or <Contactless> Transaction

The <Contact> and <Contactless> elements each contain interface logging of a transaction. The <Contact> element captures the actual command-response in the Contact Interface while the <Contactless> element captures the actual command-response in the Contactless Interface.

Depending on the test case, multiple transactions in their respective interfaces may be performed within a single test and that would result in multiple logging of <Contact> and/or <Contactless> elements.

Req 2.6 Creating Element <Contact> Or <Contactless>

When a RESET occurs (ATR is received), the <Contact> or <Contactless> element shall be created according to the interface being executed. If there are no subsequence APDU (Application Protocol Data Unit) commands following the ATR, the element will be empty i.e., <Contactless/> and does not count as a Transaction.

If not empty, the element shall contain sub-elements described in Table 3: XML Format of the Log {TestID}.xml, which populates the APDU commands and responses respectively like the below example:

<Contactless>
  <Commands>
    <CommandResponse>
      <Command>00A404000E325041592E5359532E444446303100</Command>
      <Response>6F32840E325041592E5359532E4444463031A520BF0C1D611B4F07A000000003101050105649534120434F4E544143544C4553539000</Response>
    </CommandResponse>
    <CommandResponse>
    ...
    </CommandResponse>
  </Commands>
</Contactless>

Logging of these elements (<Contact>, <Contactless>, <CommandResponse>) must be done in the exact order as how the transactions are being executed in the test.

Do not log any card personalization sequences (in case of card/mobile testing) if any.

2.2.1.1 Attribute "Exclude"

The attribute “Exclude” is conditionally used in the following elements:

• <Contact> and <Contactless>
• <CommandResponse>

This attribute shall be used by Test Tool Vendor to convey information about the exclusion of a Transaction (<Contact> or <Contactless>) or a particular set of <CommandResponse> within a Transaction.

Req 2.7 Using the Attribute

In cases where, due to the proprietary features of the product-under-test, additional transactions or commands were sent to support test execution. Although these transactions or commands are non-compliant with the test plan, they must be logged and identified using the attribute as information. When used, the attribute value must always be “true” (Boolean).

Example: <Contact Exclude=”true”>…</Contact>

Example: <CommandResponse Exclude=”true”>…</CommandResponse>

When the attribute exists in <Contact> or <Contactless> element, the exclusion applies only to the transaction represented by the element.

Likewise, when the attribute exists in a particular <CommandResponse> element, the exclusion applies only to the command-response within the element.

2.2.1.2 Sub-Element <ReaderSpecifics>

Req 2.8 Logging

The <ReaderSpecifics> element is mandatory for Reader Test Plans to log all transaction outcomes and visual check outcomes if any. Non-Reader Test Plans shall not contain this element. This section fundamentally references the [CompanionGuide], [TechReq] and the [TestPlan].

• <Transaction_Details> element leverages on Appendix A.4 (ETXN) of the [CompanionGuide], adopts the same structure and records the same data defined in Table A-2 in the [CompanionGuide]

• <VisualCheck> element is used for tests requiring visual checks according to the [TestPlan]. Please refer to the test plan for tests performing visual checking.

  The element records all the visual events that the tester is required to perform for the test and the results of the visual events are tracked within the element.

  Each visual event’s description corresponds to the check in the [TestPlan] and the check is populated into the attribute “ID” of the <Event> element defined in Table 3.

  Example:

  <ReaderSpecifics>
    ...
    <VisualCheck>
      <Events>
        <Event ID="EVT_NOTIFY_OUTCOME_APPROVED">
          <CheckPass>true</CheckPass>
          <Remarks/>
        </Event>
        <Event ID="EVT_AID_PRINTED">
          <CheckPass>true</CheckPass>
          <Remarks/>
        </Event>
      </Events>
    </VisualCheck>
  </ReaderSpecifics>
  

2.2.2 Example of a Log {TestID}.xml

Below is a log example with visual check for illustration:

This xml must start with <?xml version="1.0" encoding="UTF-8"?>

<CardTerminalLog SchemaFile="Log_Reader_Schema_v1.xsd" Tag="ART">
  <TestVerdict>PASS</TestVerdict>
  <LogDetails>
    <Date-Time>2024-12-20T15:01:04Z</Date-Time>
    <LoggingTool>
      <ProductName>ART Test Tool</ProductName>
      <ProductVersion>1.14.39.54</ProductVersion>
    </LoggingTool>
    <VTF>CDVISA01234A</VTF>
    <TestPlan>VCPS_Reader_Test_Plan_v2_2c_Build_230512</TestPlan>
    <Reference>T_0138_5_21_C04_01</Reference>
  </LogDetails>
  <Transactions>
    <Contactless Exclude="false">
      <Commands>
        <CommandResponse Exclude="false">
          <Command>00A404000E325041592E5359532E444446303100</Command>
          <Response>6F32840E325041592E5359532E4444463031A520BF0C1D611B4F07A000000003101050105649534120434F4E544143544C4553539000</Response>
        </CommandResponse>
        <CommandResponse Exclude="false">
          <Command>00A4040007A000000003101000</Command>
          <Response>6F438407A0000000031010A53850105649534120434F4E544143544C4553539F38189F66049F02069F03069F1A0295055F2A029A039C019F3704BF0C089F5A0510084008409000</Response>
        </CommandResponse>
        <CommandResponse Exclude="false">
          <Command>80A8000023832120004000000000000200000000000000084000000000000840170601001234567800</Command>
          <Response>7781C657134761739001010010D30122011234599999991F9F2701409F2608182E70627E50CC369F360200019F6C0200009F100706011203900000820220209404100203009F4B818014EF5E77653753B501FD3C0881C82C392FA09C9BD7813AD156605AAA900E1CAB3DDF029B20FA86D576DC4D9573477D613DCA1894A2E2F3D8DA24A4CDF4AE5B0A35FDC2584CBA2671A487E85FFCB720255B1BCD639E1AD780DC425BBB25099CCE5E5DE6E87D96F80B09D9A374AECB98B1534059A09E5CE9292F9B78B456EB11029000</Response>
        </CommandResponse>
        <CommandResponse Exclude="false">
          <Command>00B2021400</Command>
          <Response>7081B0908190D85C4EE9AC8CC58F9E2FEA354042FF4BF61AF7960EC1B2889A88CDBB737A20E99EB0FE0EEB15A47AEF3239786F4FAA93A635104E596254CABDBBE4C243221B0ABF35EDD7C605724D1AA49FEEAFB53DBDC4D6F11925C4E84917B906A3F879F111124F02AD5151EA4EEC41B048B88B246A3E985BF55899D1C1466135F2ABDF41ADB8B6A5DAE441F75FEA51F0CE04BA3E9A9F3201039214A2EFA5CBF02CC47D47833BB7B27ECC6962385A4B8F01519000</Response>
        </CommandResponse>
        <CommandResponse Exclude="false">
          <Command>00B2031400</Command>
          <Response>7081DA9F482A27EFFCBB4B8C937F1F87BE169475BF9B493D5DB812F35E50D11B3B34487A01BDC4DA1666E8A209FA5E419F4701039F468180B0DEF41F7DD2C7C51A41DA59E7A7D4D6157E486B61AC5163BDFE85F72E3354F7D835B81972FE4B12434B80F127F6D02AB25E40087C3A2ADF5CFAABD8DFBEC53DA9EBDCADDB626FD31DFF49491448F46EC97DFF2CA698D536C4144727D7FCD8EF675767FC993BC669F7E584AB160A41E7C363B27AE609804000DD886DDF9D5E1B9F6907011122334400009F6E042040000F5F3401005A0847617390010100105F24033012019000</Response>
        </CommandResponse>
      </Commands>
    </Contactless>
  </Transactions>
  <ReaderSpecifics>
    <Transaction_Details>
      <Test_ID>T_0138_5_21_C04_01</Test_ID>
      <Transaction_Outcome>04</Transaction_Outcome>
      <AcquirerData>
        <DE_4F>A0000000031010</DE_4F>
        <DE_9F02>000000000200</DE_9F02>
        <DE_9F03>000000000000</DE_9F03>
        <DE_9F26>182E70627E50CC36</DE_9F26>
        <DE_82>2020</DE_82>
        <DE_9F36>0001</DE_9F36>
        <DE_5F34>00</DE_5F34>
        <DE_9F7C>AABBCCDDEEFF112233445566</DE_9F7C>
        <DE_9F6E>20400000</DE_9F6E>
        <DE_9F10>06011203900000</DE_9F10>
        <DE_9F39>07</DE_9F39>
        <DE_9F1A>0840</DE_9F1A>
        <DE_TERMINAL_ENTRY_CAPABILITY>05</DE_TERMINAL_ENTRY_CAPABILITY>
        <DE_95>0000000000</DE_95>
        <DE_5F2A>0840</DE_5F2A>
        <DE_9A>170601</DE_9A>
        <DE_9C>00</DE_9C>
        <DE_9F37>12345678</DE_9F37>
        <DE_9F5B>12345678</DE_9F5B>
        <DE_9F24>12345678</DE_9F24>
        <DE_57>4761739001010010D30122011234599999991F</DE_57>
        <DE_5F20>AABBCCDDEEFF112233445566</DE_5F20>
        <DE_96/>
      </AcquirerData>
    </Transaction_Details>
    <VisualCheck>
      <Events>
        <Event ID="EVT_REQUEST_PRESENT_CARD">
          <CheckPass>true</CheckPass>
          <Remarks/>
        </Event>
        <Event ID="EVT_REMOVE_CARD_IN_PROGRESS">
          <CheckPass>true</CheckPass>
          <Remarks/>
        </Event>
        <Event ID="EVT_NOTIFY_OUTCOME_APPROVED">
          <CheckPass>true</CheckPass>
          <Remarks/>
        </Event>
      </Events>
    </VisualCheck>
  </ReaderSpecifics>
</CardTerminalLog>
<!--pGOwYbNZAm0Hd7p3HpHe/m9vIR9APobiH7Ec5HS2c7s=-->

2.3 Digital ICS Format

Req 2.9 Digital ICS XML File Naming Convention

The generated Report Summary XML file follows the naming convention: "ICS_{VTF#}_{TestPlanName}_{Timestamp}.xml", where:

• {VTF#} is the product’s assigned VTF number, such as “CDVISA01234A” or “LBVISA01234A”
• {TestPlanName} is the full name of the released test plan package, such as “VCPS_Reader_Test_Plan_v2_2d_Build_240405”
• {Timestamp} represent the time when the report is generated in UTC time format: YYYYMMDDHHMM. For example, “202501151525”.
  • YYYY: 4-digit of the year
  • MM: 2-digit month of the year
  • DD: 2-digit day of the year
  • HH: 2-digit hour using a 24-hour clock
  • MM: 2-digit minute

An example of report package name based on the above convention is “ICS_CDVISA01234A_VCPS_Reader_Test_Plan_v2_2d_Build_240405_202501151525.xml”

Req 2.10 ICS XML Structure

This file (in .xml format) details the Product’s declaration for supported features, the product’s assigned VTF number and specific information for test execution.

The digital equivalent ICS features used in the Test Plan are defined within the element. Table 4: XML Format of the Digital ICS XML File describes the elements defined within the file structure.

Table 4: XML Format of the Digital ICS XML File

Element/Node (1|2|3|4)	Occurrence (Min..Max)	Description	Content ([Condition]: DataType | Parameter | Value) / Example (e.g.)
ICSForm	1..1	The Root element of the Digital ICS file. Contains attributes: "Tag" – an identifier to distinguish the format structure that is usable only on Visa’s ART Test Plans. "SchemaFile" – references the corresponding schema (.xsd) file for this XML format.	Attributes: [M]: String | Tag | "ART" Attribute Value is defined to be “ART” [M]: String | SchemaFile File begins with “ICS*”, ends with file extension “.xsd” e.g.: <IcsForm Tag=”ART” SchemaFile=”ICS_VCPS_v2.2c_Schema_v1.xsd”>…</ IcsForm>
_ ExecutionInfo	1..1	Contains sub-elements that record the logging and test information.	e.g., <ExecutionInfo>…</ExecutionInfo>
_ _ VTF	1..1	Records the assigned VTF number of the product-under-test and must not be empty.	Text Content: [M]: String. e.g., <VTF>CDVISA01234A</VTF>
_ _ TestPlan	1..1	Records in the text content, the Test Plan to be used for testing. This information is used to populate the TestPlan field.	e.g., <TestPlan>…</TestPlan>
_ _ ExecutionType	1..1	Records in the text content, the type of execution run. The element must record either of the following: “FULL”, ”REGRESSION”, or ”TRANSACTION”. The value can be obtained from the <ExecutionType> element in the Digital ICS file.	Text Content: [M]: String. Value is case-sensitive and must be “FULL”, “REGRESSION” or “TRANSACTION” e.g., <ExecutionType>FULL</ExecutionType>
_ ICS	1..1	Contains sub-elements that record the individual support of product features. These elements are referenced from the ics*mapping_document.xlsx of the [TestPlan] and are used for the evaluation of test scoping validation.	e.g., <ICS>…</ICS>
_ _ Field Refer to Populating the “Field” element for details.	1..var	Depends on the numberof ICS defined by the Test Plan. Records in the text content, the support of the feature defined in the attribute. The element must carry a Boolean value. Contains attribute: “ID” – denotes the filename (excluding file extension) of the test case.	Text Content: [M]: Boolean. true: feature is supported. false: feature is not supported Attributes: [M]: String| ID |"OPT_XXX" The names of the product features are declared in the ics_mapping_document.xlsx of the [TestPlan], where “XXX” denotes the name of the feature. e.g., <Field ID=”OPT_ONLINE_PIN_SUPPORTED”>true</Field>

<!--BZFOjb+DQHx1tf23EwBe/dA6LbXmsZvTeC1DSO6xwbo=-->

The last line of the file shall include an XML comment containing the digest of the Base64 encoded SHA-256 algorithm of the file, like the example above. For details on deriving the hash, refer to 3 Base64 Encoded SHA-256 Hash

2.3.1. "Field" Element

Req 2.11 Populating the “Field” element

As described in Table 4, the “Field” element records the support of optional implementation features used in the respective [TestPlan] and are declared in each ics_mapping_document.xlsx of each test plan.

Each feature has a naming convention of “OPT_XXX”, where ”XXX” denotes the description of the feature. The attribute “ID” shall register every single feature used in the [TestPlan].

Typically, an ICS question corresponds to an “OPT_XXX” feature; If the user responded positively to the question i.e. (“Yes”/”True”), then the “Field” element shall have the Boolean value of the feature populated to “true”. Otherwise, the Boolean value will be “false

For example:

Question in ICS Form	Value (User Input)	Indicative Parameter in Test Plan
Cashback is supported	Yes	OPT_CASHBACK_SUPPORTED
Online PIN is supported	No	OPT_ONLINE_PIN_SUPPORTED

The table will translate to the “Field” elements:

• <Field ID="OPT_CASHBACK_SUPPORTED">true</Field>

• <Field ID="OPT_ONLINE_PIN_SUPPORTED">false</Field>

Req 2.12 Incorporating Additional Rules

IMPORTANT: Each generation of Digital ICS file is unique to each test plan. Developers generating the digital file shall always refer to the corresponding [TechReq] of the test plan that the generation is intended for.

This is to manage and adapt additional rules (if any) that are required for specific “OPT_XXX”s. Therefore, to result in the correct set of executable tests, it is critical to ensure that the generated digital ICS file is in accordance with the expected values’ setting as per, if any, specifically described in the [TechReq].

2.3.2 Example of the Digital ICS XML File

Below is an extract of the file for illustration purpose:

This xml document should start with <?xml version="1.0" encoding="utf-8"?>

<ICSForm Tag="ART" SchemaFile="ICS_VRTPKS_v1.2a_Schema_v2.xsd">
  <ExecutionInfo>
    <VTF>TP103100004</VTF>
    <TestPlan>VRTPKS_Test_Plan_v1_2a_Build_230512</TestPlan>
    <ExecutionType>FULL</ExecutionType>
  </ExecutionInfo>
  <ICS>
    <Field ID="OPT_SELECT_PPSE_DF_NAME_MANDATORY">true</Field>
    <Field ID="OPT_SELECT_ADF_DF_NAME_MANDATORY">true</Field>
    <Field ID="OPT_ONLINE_PIN_SUPPORTED">true</Field>
    <Field ID="OPT_CVM_REQUIRED_LIMIT_CHECK_SUPPORTED">true</Field>
  </ICS>
</ICSForm>
<!--L4RQfTxPzl/BaND6qM2wXz0yBGmsdj5/VZi1MMj0Rxk=-->

Note: The value of the Digest is for illustration purposes only and does not reflect the actual calculated Digest value.

3 Base64 Encoded SHA-256 Hash

Req 3.1 Message Digest

To protect the content integrity of the digital file, the file content will be hashed for each file. The data-to-hash (content which will be involved in the hashing algorithm) will be applied with a Base64 Encoded SHA-256 algorithm to generate a digest value (or checksum).

The value shall be calculated for each file and be included in an XML comment on the last line of each file. Files receiver will be able to verify the digest value of each file to ensure that the file has not been changed manually without updating the digest value.

A typical header and trailer example of a ReportSummary.xml is shown below with a sample digest for illustration:

<TestReport Tag="ART" SchemaFile="ReportSummary_Schema_v2.xsd">
  ...
</TestReport>
<!--LEKROK7X2EfTwSgfqHKwJIodEUXeCOjMCnBApCmPs6s=-->

Note that other than the example provided in Section 3.2, the digest value illustrated in this document may not reflect the actual calculated value and is meant for illustration purposes.

3.1 Base64 Encoded SHA-256 Hash

Req 3.2 Hashing Procedure

The following defines the content to be hashed and describes the procedures to apply Base64 encoded SHA-256 algorithm. The SHA-256 is defined in [FIPS PUB 10-4].

The data-to-minified shall consist of the entire content of the XML file, excluding the filename and the <?xml version="1.0" encoding="utf-8"?> declaration, from the start of the Root Element tag to the end of the Root Element tag. That data must be minified before applying the SHA-256 hash function. The minification process involves the removal of insignificant whitespaces, indentations, tabs, and line breaks. This process generate entire-minified-content that will be hashed as described in the next step.

The data-to-hash shall consist of the entire-minified-content within the root element of the file (from Node 1 onwards i.e., the entire content of <RootTag> including the root tag and all existing attributes), excluding the comment line itself. The Base64 encoded SHA-256 algorithm is then applied to the data-to-hash to generate the digest value. The resultant digest value shall be included in an XML comment and injected into the last line of each digital file.

Note: Root element tag <RootTag> of Report Summary is <TestReport> and root element tag <RootTag> of transaction log is <CardTerminalLog>

3.2 Example of the Digest Computation

The following is an example of a simple xml file, with added whitespaces, indentation, line-breaks, included deliberately for illustration purposes. This example will highlight the derivation of the Digest Value:

This xml document should start with <?xml version="1.0" encoding="utf-8"?>

<CardTerminalLog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Tag="ART" SchemaFile="Log_Schema_v1.xsd">
  <TestVerdict>PASS</TestVerdict>
  <LogDetails>
    <Date-Time>2024-05-10T14:30:19Z</Date-Time>
    <LoggingTool>
      <ProductName>ICCSimTMat VRTPKS</ProductName>
      <ProductVersion>4.203.2</ProductVersion>
    </LoggingTool>
    <TestPlan>VRTPKS_Test_Plan_v1_2a_Build_230512</TestPlan>
    <Reference>T_326_T2P_5_20_C01_01</Reference>
  </LogDetails>
  <Transactions>
    <Contactless>
      <Commands>
        <CommandResponse Exclude="true">
          <Command>00A4040007D276000085010100</Command>
          <Response>6A82</Response>
        </CommandResponse>
        <CommandResponse Exclude="true">
          <Command>00A4040007D276000085010000</Command>
          <Response>6A82</Response>
        </CommandResponse>
        <CommandResponse Exclude="true">
          <Command>00A4040007D276000085010100</Command>
          <Response>6A82</Response>
        </CommandResponse>
        <CommandResponse Exclude="true">
          <Command>00A4040007D276000085010000</Command>
          <Response>6A82</Response>
        </CommandResponse>
        <CommandResponse>
          <Command>00A404000E325041592E5359532E444446303100</Command>
<Response>6F32840E325041592E5359532E4444463031A520BF0C1D611B4F07A000000003101050105649534120434F4E544143544C4553539000</Response>
        </CommandResponse>
        <CommandResponse>
          <Command>00A4040007A000000003101000</Command>
<Response>6F438407A0000000031010A53850105649534120434F4E544143544C4553539F38189F66049F02069F03069F1A0295055F2A029A039C019F3704BF0C089F5A0510084008409000</Response>
        </CommandResponse>
        <CommandResponse>
<Command>80A800002383212280400000000000020000000000000008400000000000084024010120EF3B2BB800</Command>  <Response>775857134761739001010010D30122011234599999991F9F2701009F2608DA19325C0FF809A29F360200015F3401009F6E04204000009F6C0200009F100706011203800000820220205F200E4E616D6530696E205265636F72649000</Response>
        </CommandResponse>
      </Commands>
    </Contactless>
  </Transactions>
  <ReaderSpecifics>
    <Transaction_Details>
      <Test_ID>T_326_T2P_5_20_C01_01</Test_ID>
      <Transaction_Outcome>20</Transaction_Outcome>
      <AcquirerData>
        <DE_9F02>000000000200</DE_9F02>
        <DE_9F03>000000000000</DE_9F03>
        <DE_9F26>DA19325C0FF809A2</DE_9F26>
        <DE_82>2020</DE_82>
        <DE_9F36>0001</DE_9F36>
        <DE_5F34>00</DE_5F34>
        <DE_9F7C />
        <DE_9F6E>20400080</DE_9F6E>
        <DE_9F10>06011203800000</DE_9F10>
        <DE_9F39>07</DE_9F39>
        <DE_9F1A>0840</DE_9F1A>
        <DE_TERMINAL_ENTRY_CAPABILITY>08</DE_TERMINAL_ENTRY_CAPABILITY>
        <DE_95>0000000000</DE_95>
        <DE_5F2A>0840</DE_5F2A>
        <DE_9A>240101</DE_9A>
        <DE_9C>20</DE_9C>
        <DE_9F37>EF3B2BB8</DE_9F37>
        <DE_9F5B />
        <DE_9F24 />
        <DE_57>4761739001010010D30122011234599999991F</DE_57>
      </AcquirerData>
      <IRWINData />
    </Transaction_Details>
    <VisualCheck />
  </ReaderSpecifics>
</CardTerminalLog>
<!--EHcpMEHD3XEed3vot4EgfJ65JXiqKaC61NrU61VRrL8=-->

Minified Data-to-Hash:

<CardTerminalLog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Tag="ART" SchemaFile="Log_Schema_v1.xsd"><TestVerdict>PASS</TestVerdict><LogDetails><Date-Time>2024-05-10T14:30:19Z</Date-Time><LoggingTool><ProductName>ICCSimTMat VRTPKS</ProductName><ProductVersion>4.203.2</ProductVersion></LoggingTool><TestPlan>VRTPKS_Test_Plan_v1_2a_Build_230512</TestPlan><Reference>T_326_T2P_5_20_C01_01</Reference></LogDetails><Transactions><Contactless><Commands><CommandResponse Exclude="true"><Command>00A4040007D276000085010100</Command><Response>6A82</Response></CommandResponse><CommandResponse Exclude="true"><Command>00A4040007D276000085010000</Command><Response>6A82</Response></CommandResponse><CommandResponse Exclude="true"><Command>00A4040007D276000085010100</Command><Response>6A82</Response></CommandResponse><CommandResponse Exclude="true"><Command>00A4040007D276000085010000</Command><Response>6A82</Response></CommandResponse><CommandResponse><Command>00A404000E325041592E5359532E444446303100</Command><Response>6F32840E325041592E5359532E4444463031A520BF0C1D611B4F07A000000003101050105649534120434F4E544143544C4553539000</Response></CommandResponse><CommandResponse><Command>00A4040007A000000003101000</Command><Response>6F438407A0000000031010A53850105649534120434F4E544143544C4553539F38189F66049F02069F03069F1A0295055F2A029A039C019F3704BF0C089F5A0510084008409000</Response></CommandResponse><CommandResponse><Command>80A800002383212280400000000000020000000000000008400000000000084024010120EF3B2BB800</Command><Response>775857134761739001010010D30122011234599999991F9F2701009F2608DA19325C0FF809A29F360200015F3401009F6E04204000009F6C0200009F100706011203800000820220205F200E4E616D6530696E205265636F72649000</Response></CommandResponse></Commands></Contactless></Transactions><ReaderSpecifics><Transaction_Details><Test_ID>T_326_T2P_5_20_C01_01</Test_ID><Transaction_Outcome>20</Transaction_Outcome><AcquirerData><DE_9F02>000000000200</DE_9F02><DE_9F03>000000000000</DE_9F03><DE_9F26>DA19325C0FF809A2</DE_9F26><DE_82>2020</DE_82><DE_9F36>0001</DE_9F36><DE_5F34>00</DE_5F34><DE_9F7C /><DE_9F6E>20400080</DE_9F6E><DE_9F10>06011203800000</DE_9F10><DE_9F39>07</DE_9F39><DE_9F1A>0840</DE_9F1A><DE_TERMINAL_ENTRY_CAPABILITY>08</DE_TERMINAL_ENTRY_CAPABILITY><DE_95>0000000000</DE_95><DE_5F2A>0840</DE_5F2A><DE_9A>240101</DE_9A><DE_9C>20</DE_9C><DE_9F37>EF3B2BB8</DE_9F37><DE_9F5B /><DE_9F24 /><DE_57>4761739001010010D30122011234599999991F</DE_57></AcquirerData><IRWINData /></Transaction_Details><VisualCheck /></ReaderSpecifics></CardTerminalLog>

Base64 Encoded SHA-256 Digest Value:
<!--EHcpMEHD3XEed3vot4EgfJ65JXiqKaC61NrU61VRrL8=-->

4 Schema (.xsd) Files

Req 4.1 Schema Definition

For each XML file format, a corresponding schema (.xsd) file is accompanied and the schema is conformed to the W3C XML Schema Definition Language (XSD), Version 1.1. Each schema file describes the structure of the XML and contains rules for the XML content.

The following schema files will reside within each [TestPlan] Package that supports digital reporting:

• ReportSummary_Schema_v#.xsd for ReportSummary.xml (filename begins with “ReportSummary*”)
• Log_Reader_Schema_v#.xsd for Reader Testplan Transaction log {TestID}.xml (filename begins with “Log*”)
• Log_Card_Schema_v#.xsd for Non-Reader Testplan Transaction log {TestID}.xml (filename begins with “Log*”)
• ICS_XXX_v#.xsd for digital ICS XML File (filename begins with “ICS*”)

where “#” is the version number.

The version number of each file will be incremented independently if there are changes made to the schema.

Req 4.2 Populating Schema File Name

Test Tool Vendor is required to pick up the correct schema used and populate the corresponding schema file in the attribute of the Root Element of the XML format. For example:

• ReportSummary.xml:

  <TestReport Tag=”ART” SchemaFile=”ReportSummary_Schema_v1.xsd”>…</TestReport>
  

• Reader Testplan {TestID}.xml:

  <CardTerminalLog Tag=”ART” SchemaFile=”Log_Reader_Schema_v1.xsd”>…</CardTerminalLog>
  

• Non-Reader Testplan {TestID}.xml:

  <CardTerminalLog Tag=”ART” SchemaFile=”Log_Card_Schema_v1.xsd”>…</CardTerminalLog>
  

• Digital ICS XML File:

  <ICSForm Tag=”ART” SchemaFile=”ICS_VRTPKS_v1.0a_Schema_v1.xsd”>…</ICSForm>
  

4.1 W3C XML Schema Definition Language, Version 1.1

Req 4.3 Support for XML Schema Requirement, Version 1.1

Tools that are utilizing the schema shall support version 1.1 of the Requirement: W3C XML Schema Definition Language. This is to support the usage of the “assert” component defined in the Requirement and an example of the XML representation for the xs:assert component is:

<xs:assert test="Field[@ID='OPT_ONLINE_ONLY'] eq true()" id="check_online_only">

The test attribute in the xs:assert component specifies an XPath expression and conforms to the XML Path Language 2.0 (Second Edition).

The ICS schema implements condition checking of the existence and values of related elements and attributes in the Digital ICS XML file using this “assert” component. This component primarily checks against the elements within the of the .xml file to ensure correctness of ICS features’ selection i.e., certain ICS features are dependent on another ICS feature.

Developers generating the Digital ICS XML file shall ensure the generated file adheres to the assertion checks in the schema. Below is a snippet of the schema’s usage of the assertion component:

This xml must start with <?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning"
           vc:minVersion="1.1">
    <xs:element name="ICSForm">
        <xs:complexType>
            <xs:all>
                <xs:element ref="ExecutionInfo"/>
                <xs:element ref="ICS"/>
            </xs:all>
            <xs:attribute name="Tag" use="required" fixed="ART">
                <xs:simpleType>
                    <xs:restriction base="xs:string"/>
                </xs:simpleType>
            </xs:attribute>
            <xs:attribute name="SchemaFile" use="required">
                <xs:simpleType>
                    <xs:restriction base="xs:string">
                        <xs:pattern value="(ICS_.+\.xsd)|(ICS_.+\.XSD)"/>
                    </xs:restriction>
                </xs:simpleType>
            </xs:attribute>
        </xs:complexType>
    </xs:element>
    <xs:element name="ExecutionInfo">
        <xs:complexType>
            <xs:all>
                <xs:element name="VTF" type="nonEmptyString"/>
                <xs:element name="TestPlan" type="nonEmptyString"/>
                <xs:element ref="ExecutionType"/>
            </xs:all>
        </xs:complexType>
    </xs:element>
    <xs:element name="ExecutionType">
        <xs:simpleType>
            <xs:restriction base="xs:string">
                <xs:enumeration value="FULL"/>
                <xs:enumeration value="REGRESSION"/>
                <xs:enumeration value="TRANSACTION"/>
            </xs:restriction>
        </xs:simpleType>
    </xs:element>
    <xs:element name="ICS">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="Field" minOccurs="18" maxOccurs="18"/>
            </xs:sequence>
            <xs:assert test="Field[@ID='OPT_ONLINE_ONLY'] eq true()" id="check_online_only">
                <xs:annotation>
                    <xs:documentation>
                        OPT_ONLINE_ONLY must be supported for Tap to Phone kernel implementation.
                    </xs:documentation>
                </xs:annotation>
            </xs:assert>
            <xs:assert test="Field[@ID='OPT_CVM_REQUIRED_LIMIT_CHECK_SUPPORTED'] eq true()" id="check_cvm_required">
                <xs:annotation>
                    <xs:documentation>
                        OPT_CVM_REQUIRED_LIMIT_CHECK_SUPPORTED must be supported for Tap to Phone kernel implementation.
                    </xs:documentation>
                </xs:annotation>
            </xs:assert>
            <xs:assert
                    test="if (Field[@ID='OPT_INDEPENDENT_PARAMS_FOR_MANUAL_CASH_SUPPORTED'] eq true() and Field[@ID='OPT_MANUAL_CASH_SUPPORTED'] eq false()) then false() else true()"
                    id="check_manual_cash_support">
                <xs:annotation>
                    <xs:documentation>
                        If OPT_INDEPENDENT_PARAMS_FOR_MANUAL_CASH_SUPPORTED is supported, OPT_MANUAL_CASH_SUPPORTED must
                        be supported.
                    </xs:documentation>
                </xs:annotation>
            </xs:assert>
            <xs:assert
                    test="if (Field[@ID='OPT_INDEPENDENT_PARAMS_FOR_CASHBACK_SUPPORTED'] eq true() and Field[@ID='OPT_CASHBACK_SUPPORTED'] eq false()) then false() else true()"
                    id="check_cashback_support">
                <xs:annotation>
                    <xs:documentation>
                        If OPT_INDEPENDENT_PARAMS_FOR_CASHBACK_SUPPORTED is supported, OPT_CASHBACK_SUPPORTED must be
                        supported.
                    </xs:documentation>
                </xs:annotation>
            </xs:assert>
            <xs:assert
                    test="if (Field[@ID='OPT_DISPLAY_AMT_ON_CARD_PROMPT'] eq true() and Field[@ID='OPT_DISPLAY_SUPPORTED'] eq false()) then false() else true()"
                    id="check_display">
                <xs:annotation>
                    <xs:documentation>
                        If OPT_DISPLAY_AMT_ON_CARD_PROMPT is supported, OPT_DISPLAY_SUPPORTED must be supported.
                    </xs:documentation>
                </xs:annotation>
            </xs:assert>
            <xs:assert
                    test="if ((Field[@ID='OPT_PRINT_RECEIPT_FOR_APPROVED_TXN_SUPPORTED'] eq true() or Field[@ID='OPT_PRINT_RECEIPT_FOR_DECLINED_TXN_SUPPORTED'] eq true()) and Field[@ID='OPT_RECEIPT_PRINTING_SUPPORTED'] eq false()) then false() else true()"
                    id="check_print_receipt">
                <xs:annotation>
                    <xs:documentation>
                        If OPT_PRINT_RECEIPT_FOR_APPROVED_TXN_SUPPORTED or OPT_PRINT_RECEIPT_FOR_DECLINED_TXN_SUPPORTED
                        is supported, OPT_RECEIPT_PRINTING_SUPPORTED must be supported.
                    </xs:documentation>
                </xs:annotation>
            </xs:assert>
            <xs:assert
                    test="if (Field[@ID='OPT_KEY_REVOCATION_SUPPORTED'] eq true() and Field[@ID='OPT_TRANSIT_SUPPORTED'] eq false()) then false() else true()"
                    id="check_transit">
                <xs:annotation>
                    <xs:documentation>
                        If OPT_KEY_REVOCATION_SUPPORTED is supported, OPT_TRANSIT_SUPPORTED must be supported.
                    </xs:documentation>
                </xs:annotation>
            </xs:assert>
            <xs:assert
                    test="if (Field[@ID='OPT_ADDITIONAL_IDS_IN_POI_INFORMATION_SUPPORTED'] eq true() and Field[@ID='OPT_TRANSIT_SUPPORTED'] eq false()) then false() else true()"
                    id="check_ids_poi_transit">
                <xs:annotation>
                    <xs:documentation>
                        If OPT_ADDITIONAL_IDS_IN_POI_INFORMATION_SUPPORTED is supported, OPT_TRANSIT_SUPPORTED must be
                        supported.
                    </xs:documentation>
                </xs:annotation>
            </xs:assert>
        </xs:complexType>
        <xs:key name="icsID">
            <xs:selector xpath="Field"/>
            <xs:field xpath="@ID"/>
        </xs:key>
    </xs:element>
    <xs:element name="Field">
        <xs:complexType>
            <xs:simpleContent>
                <xs:extension base="xs:boolean">
                    <xs:attribute name="ID" use="required">
                        <xs:simpleType>
                            <xs:restriction base="xs:string">
                                <xs:enumeration value="OPT_SELECT_PPSE_DF_NAME_MANDATORY"/>
                                <xs:enumeration value="OPT_SELECT_ADF_DF_NAME_MANDATORY"/>
                                <xs:enumeration value="OPT_ONLINE_PIN_SUPPORTED"/>
                                <xs:enumeration value="OPT_CVM_REQUIRED_LIMIT_CHECK_SUPPORTED"/>
                                <xs:enumeration value="OPT_REFUNDS_CREDITS_SUPPORTED"/>
                                <xs:enumeration value="OPT_ONLINE_ONLY"/>
                                <xs:enumeration value="OPT_MANUAL_CASH_SUPPORTED"/>
                                <xs:enumeration value="OPT_INDEPENDENT_PARAMS_FOR_MANUAL_CASH_SUPPORTED"/>
                                <xs:enumeration value="OPT_CASHBACK_SUPPORTED"/>
                                <xs:enumeration value="OPT_INDEPENDENT_PARAMS_FOR_CASHBACK_SUPPORTED"/>
                                <xs:enumeration value="OPT_DISPLAY_SUPPORTED"/>
                                <xs:enumeration value="OPT_DISPLAY_AMT_ON_CARD_PROMPT"/>
                                <xs:enumeration value="OPT_RECEIPT_PRINTING_SUPPORTED"/>
                                <xs:enumeration value="OPT_PRINT_RECEIPT_FOR_APPROVED_TXN_SUPPORTED"/>
                                <xs:enumeration value="OPT_PRINT_RECEIPT_FOR_DECLINED_TXN_SUPPORTED"/>
                                <xs:enumeration value="OPT_TRANSIT_SUPPORTED"/>
                                <xs:enumeration value="OPT_KEY_REVOCATION_SUPPORTED"/>
                                <xs:enumeration value="OPT_ADDITIONAL_IDS_IN_POI_INFORMATION_SUPPORTED"/>
                            </xs:restriction>
                        </xs:simpleType>
                    </xs:attribute>
                </xs:extension>
            </xs:simpleContent>
        </xs:complexType>
    </xs:element>
    <xs:simpleType name="nonEmptyString">
        <xs:restriction base="xs:string">
            <xs:minLength value="1">
                <xs:annotation>
                    <xs:documentation>
                        Empty String not allowed
                    </xs:documentation>
                </xs:annotation>
            </xs:minLength>
        </xs:restriction>
    </xs:simpleType>
</xs:schema>